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[57] 



ABSTRACT 



In a cryptographic module, a User Defined Function 
(UDF) facility is provided which provides users with 
the capability of defining and creating custom functions 
to meet their cryptographic processing needs. The 
cryptographic module is contained within a physically 
and logically secure environment and comprises a pro- 
cessing unit and memory connected to the processing 
unit. The memory includes code for translating User 
Defined Functions (UDFs) into a machine-readable 
form and at least one command for operating on the 
UDFs. The UDFs are loaded into and executed in the 
secure area of the cryptographic module without com- 
promising the total security of the transaction security 
system. 



43 Claims, 6 Drawing Sheets 
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programmable read only memory (EPROM) used in the 
USER DEFINED FUNCTION FACILITY cryptographic module is programmed with a set of 

defined cryptographic functions. The particular crypto- 
FIELD OF THE INVENTION graphic functions that are programmed into the 

This invention relates to a User Defined Function 5 HPROM are selected by determining what functions 
(UDF) facility which provides users with the capability would desirable to most users of the cryptographic 
of defining and creating custom functions to meet their . module. However, there may be additional crypto- 
unique cryptographic processing needs. These User graphic functions which a particular user would like to 
Defined Functions (UDFs) are loaded into and exe- have added to a cryptographic module. These addi- 
cuted in the secure area of a cryptographic module 10 tional functions may be unknown at the time the 
without compromising the total security of a transac- EPROM is programmed, they may be user specific and 
tion security system. only required by a few users, or they may involve pro- 

„ prietary steps or processes that the user does not want 

BACKGROUND OF THE INVENTION disclosed. In any event, it is not commercially feasible 

In the finance and transaction processing industry, 55 to add all of these additional functions to the functions 
there is often a need to protect data contained within a that are programmed into the EPROM. Using present 
computer system and transmitted over a computer net- cryptographic modules, the EPROM would have to be 
work. Over the years, a number of mechanisms have removed from the module, erased, and then repro- 
been developed to meet this need. grammed to include the additional functions. These 

One of the mechanisms that has been developed to 20 additional steps can be costly and time consuming, and 
protect data being transmitted over a computer net- maybe even impossible, because the physical protection 
work is the cryptographic processor. A cryptographic \ s specifically designed to inhibit such activity, 
processor accomplishes this by transforming the data to OT tw w « v -rue Txn/trxrri^xr 

be protected into an unrecognizable form using a cryp- SUMMARY Or THE INVENTION 

tographic scheme and a key. Even with knowledge of 25 ^ present invention eliminates the need that exists 
the cryptographic scheme, the recognizable form of the m p resent cryptographic modules to remove, erase, and 
data is inaccessible while the data is being transmitted rep rogram the EPROM whenever it is desired to add an 
over the computer network so long as the key is kept additional cryptographic function to the defined cryp- 
secret. Cryptographic processors can be created to t0 g rap hic functions that are programmed into the 
implement a variety of cryptographic schemes for the 30 EPROM. 

encryption and decryption of data. Generally, the present invention provides users with 

However, since it is necessary for the keys used by a ^ bim of defining and creating custom func . 
cryptographic processor to be stored and transmitted fa additiQn tQ ^ functions prograinm ed 

within the computer system, additional protection is E PROM,.to meet their unique cryptographic 

required to prevent unauthorized access to > and copying 3S m needs ^ User Defined Functions 

of the keys. A mechanism that has been devek>ped o * * and m ^ m 

further P rctec <^ area of the cryptographic module without compromis- 

Sen 5 £232 ^*^^£l£ in r hetota J secu ^ 

enables access to data in a protected memory only if the 40 I« accordance ™* 

access is in response to an instruction that was previ- P««t mvention, tt^ User Defined Funcuon (TOF) 

ously fetched from the same memory or if the micro- &«hty includes a UDF machine, a set of UDF untrue- 

processor is in an input/output cycle. Thus, the cir- tions, and a set of UDF commands The UDFs are 

cuitry prevents unauthorized access to data within the created using the set of UDF instructions. The UDF 

protected memory 45 programmer selects particular instructions from the set 

While these types of mechanisms protect data from of UDF instructions and arranges them in a sequence 
electronic attacks, they are insufficient to protect data appropriate to implement the desired function of the 
from physical attacks. Some well known forms of physi- UDF. The UDF input file that is createdis then assem- 
cal attack are mechanical or chemical intrusion, temper- Wed using a macroassembler. Next, a UDF Set is ere. 
ature modification, and radiation exposure. One mecha- 50 ated by specifying the UDFsto be included m the UDF 
nism that has been developed to protect data against Set using the appropriate UDF instructions. The UDF 
physical attack is an intrusion barrier such as that de- Set definition file that is created is then assembled and 
scribed in U.S. Pat. No. 5,027,397 to Double, of com- linked together with the previously assembled UDFs 
mon assignee with this application. The intrusion bar- into a single UDF Set. The executable UDF Set may be 
rier disclosed in Double includes a screen material sur- 55 used as input to a UDF simulator to verify the operation 
rounding the electronic assembly which screen material of the individual UDFs. The UDFs are then -managed 
has formed thereon fine conductive lines and an electri- using the set of UDF commands. The set of UDF corn- 
eal supply and signal detection means to detect a change mands enables the user to register, load, verify, delete, 
in the resistance of the conductive lines. The intrusion invoke, and query the UDFs contained in the UDF Set. 
barrier disclosed in Double further includes tempera- €0 Even though the UDFs are loaded into and executed in 
ture sensing means and radiation detection means to the secure area of the cryptographic module, the total 
detect a predetermined decrease in the temperature or security of the transaction security system is not corn- 
increase in the radiation, respectively. promised. 

Using a cryptographic processor in conjunction with Compromise is avoided by allowing the UDF pro- 

the electrical and physical protection devices of Levien 65 grammer to use only the pre-defined UDF instructions 

and Double, a secure cryptographic module can be and by limiting the data areas that are accessible to the 

created. However, a major drawback of such a crypto- UDF instructions. Thus, the UDF programmer is not 

graphic module is its lack of flexibility. The erasable able to access any of the data areas outside the UDF 
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machine in the secure area of the cryptographic mod- The microprocessor 14 generates status signals, in- 

ule. It is also possible to discriminate between crypto- eluding MCS, IF, UCS, LCS, and MR. These status 

graphic keys that may be used by a UDF and crypto- signals are generated if there is a middle chip select, an 

graphic keys that are excluded from use in a UDF. instruction fetch, an upper chip select, a lower chip 

Other features and advantages of the present inven- 5 select, or a memory read, respectively. The electrical 

tion will become apparent from the following detailed circuitry of gate 28 monitors these status signals, 

description and accompanying drawings which form a The UCS and LCS status signals are applied to an OR 

part of the specification. 8 ate 34 The output from OR gate 34 is then applied 

along with the MR status signal to an AND gate 36. If 

BRIEF DESCRIPTION OF THE DRAWINGS 10 the upper chip 16 or the lower chip 18 is selected and a 

FIG. 1 is a schematic drawing of a prior art crypto- memory read is being performed, the output from AND 

graphic module- ^ wil1 active ^ a switch 38 will be opened 

FIG. 2 is a schematic drawing of the circuitry of a preventing access to the inner jwrtion of the bus 30. 

gate in a cryptographic module; The MCS status signal and the IF status signal are 

FIG. 3 is a schematic drawing of a cryptographic « 

module with the addition of a UDF facility constructed «° » ^ t0 \ n P ut f of » R "? flop 42. If the 

according to the principles of the present invention; J™** <*«P * » ' «"«ted and an mstraction fetch is 

FIG. 4 is a schematic drawing of a UDF machine; **** performed the flip flop ,42 is set Jhe output Q of 

FIG. 5 is a flow chart illustrating the UDF develop- , ft J^ # tttt .^^ M ^^i&SS£ 
t *vw>« o«ri 20 UCS status signal and to an AND gate 46 along with the 

* I 1 ;ii„ct M t; n » o pttsi rfprivMinn L ^S status signal. If the nip flop 42 has been set, access 

FIG 6 is a flow chart illustrating a PIN derivation ^ ^ ^ ^ ^ Qf ^ ^ chip 18 is blocke(Jt 

algorithm. ^ ucs stfltus signaJ ^ the IF smu& signal are 

DETAILED DESCRIPTION OF THE applied to an AND gate 48 and the LCS status signal 

PREFERRED EMBODIMENT 25 and the IF status signal are applied to an AND gate 50. 

„ , . . , - £i m „ The output of AND gate 48 and the output of AND 

Referring now to the drawings and for the present to 5Q ^ ^ Ued tQ afl QR $2 If the 

FIG. 1, a typical prior art cryptographic module 10 is ^. u Qf ^ , ower chi 18 {$ ^ an mstruc . 

shown. The cryptographic module 10 provides a secure ^ fetch is bemg performedj the flip flop 42 is reset, 
environment for a cipher processor 12, a microproces- 30 the flip flop 42 has been reset( access to the upper 

sor 14, erasable programmable read only memory c hip 16 or the lower chip 18 is permitted. 
(EPROM) or upper chip 16, and random access mem- . FIG. 3 shows a preferred embodiment of a crypto- 
ory (RAM) or lower chip 18. The cryptographic mod- gra phic module 10' constructed according to the princi- 
ule 10 is controlled by the microprocessor 14, using the ples of the present invention. The cryptographic mod- 
secure memories 16 and 18. Cryptographic keys, which 35 ule 10 / comprises the elements of the cryptographic 
are used for the encryption and decryption of data, are module 10 with the addition of a User Defined Function 
stored in the lower chip 18 which is kept active by a (UDF) facility. The UDF facility includes a UDF ma- 
battery backup circuit 20 and a battery 22. In order to cnine 54j a set 0 f UDF instructions which are used to 
protect against a physical attack on the cryptographic create a UDF Set 56, and a set of UDF commands 58, 
module 10, the battery backup circuit 20 operates under 40 50, 62, 64, 66, and 68. 

the control of a tamper protection and detection circuit j n tne preferred embodiment, the code which imple- 
24 which is designed to detect attempts to penetrate the ments the UDF machine 54 and the set of UDF com- 
cryptographic module 10 by physical attack. The physi- mands 58, 60, 62, 64, 66, and 68 is loaded into the upper 
cal protection of the cryptographic module 10 is de- cn jp j$ f rom media, such as a diskette, or another mem- 
scribed in greater detail in said U.S. Pat. No. 5,027,397, 45 orv during manufacture of the cryptographic module 
incorporated herein by reference and having the same ifj'. It will be understood that if the cryptographic mod- 
assignee as this application. (However, other physical u ] e 10' is designed with an upper chip 16 that is pro- 
protection devices can be used.) The microprocessor 14 grammable after manufacture, the code which imple- 
uses random access memory (RAM) or middle chip 26 ments the UDF machine 54 and the set of UDF com- 
which is located outside of the cryptographic module 50 mands 58, 60, 62, 64, 66, and 68 will be loadable from a 
10, in addition to the secure memories 16 and 18. To media 55 by other programs 57, which are already in the 
prevent access to the contents of the secure memories upper chip 16, along path 59 at a later time. 
16 and 18 while the microprocessor 14 or the cipher The upper chip 16 in the cryptographic module 10' is 
processor 12 is performing a secure process, a gate 28 programmed with a set of defined cryptographic func- 
opens the connection of an inner portion of a bus 30 to 55 tions. The UDF facility provides users with the capabil- 
an outer portion of a bus 32 so that any information on ity of defining and creating custom functions, in addi- 
the inner portion of the bus 30 cannot be read from tion to the functions already programmed into the 
outside of the cryptographic module 10 at contacts upper chip 16, to meet their unique cryptographic pro- 
connected to the outer portion of the bus 32. The opera- cessing needs. These User Defined Functions (UDFs) 
tion of gate 28 is shown in greater detail in FIG. 2. 60 are created using the set of UDF instructions. The UDF 
Gate 28 includes electrical circuitry designed to pre- programmer selects particular instructions from the set 
vent access to the inner portion of the bus 30 while the of UDF instructions and arranges them in a sequence 
microprocessor 14 is performing a read from the upper appropriate to implement the desired function of the 
chip 16 or the lower chip 18. The electrical circuitry is UDF. The UDF input file that is created is then assem- 
further designed to prevent access to the upper chip 16 65 bled using a macroassembler. Next, a UDF Set is cre- 
or the lower chip 18 while the microprocessor 14 is ated by specifying the UDFs to be included in the UDF 
executing an instruction which was fetched from the Set using the appropriate UDF instructions. The UDF 
middle chip 26. Set definition file that is created is then assembled and 
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linked together with the previously assembled UDFs 
into a single UDF Set. The executable UDF Set may be 
used as input to a UDF simulator to verify the operation 
of the individual UDFs. The UDFs are then managed 
using the set of UDF commands 58, 60, 62, 64, 66, and 
68. The set of UDF commands 58, 60, 62, 64, 66, and 68 
enables the user to register, load, verify, delete, invoke, 
and query the UDFs, respectively. Even though the 
UDFs are loaded into the secure area of the crypto- 
graphic module 10' from media 102 outside of the cryp- 
tographic module 10' (as shown in FIG. 5 and discussed 
in greater detail below) and executed in the secure area 
of the cryptographic module 10', the total security of 
the transaction security system is not compromised. 

Compromise is avoided by allowing the UDF pro- 
grammer to use only the pre-defined UDF instructions 
to create a UDF. The iow level' instructions or opera- 
tions that are understandable by the microprocessor 14 
cannot be included in a UDF. Additionally, the data 



10 



15 



performed by code that is loaded into middle chip 26. If 
the second bit is not active, usage of the key in opera- 
tions performed by code that is loaded into middle chip 
26 is blocked. If the third bit is active, the key is permit- 
ted to be used in normal (non-UDF) operations. If the 
third bit is not active, usage of the key in normal (non- 
UDF) operations is blocked. The use of these three bits 
makes it possible to discriminate among keys for use in 
the various combinations of operations. For example, a 
key can be created that can only be used in the UDF 
machine. Thus, the key cannot be used in the normal 
(non-UDF) operations and compromise of data outside 
the UDF machine is avoided. 

The keys that are controlled by the description above 
are keys that are encrypted under the master key. In the 
recovery of a key, the user has a clear copy of the key. 
Therefore, the UDF code must be carefully written to 
ensure that no keys are exposed. 
In one alternate embodiment, the keys are maintained 



areas that are accessible to the UDF instructions are 20 in an encrypted form and the encrypted form is passed 



limited. Thus, the UDF programmer can only access 
data that is located within the UDF machine 54. The 
UDF machine 54 prevents the UDF programmer from 
accessing data that is outside the UDF machine 54. 
Attempts to access data outside the limits of the UDF 25 
machine 54 result in an error signal being generated. 

Machine level code can also be loaded into and exe- 
cuted out of middle chip 26 without compromising the 
total security of the transaction security system. Corn- 



to all utilizing UDF instructions. This supports chained 
operations where a fust key is decrypted under the 
master key and then is used directly to decrypt a second 
key without exposing the first key in clear form. This 
enables the second key to be used in the UDF only if the 
CVs for the first key and the second key permit those 
keys to be used in a UDF (i.e. the first bit is active in 
both CVs). This embodiment requires the deletion of 
the UDF instruction that allows keys to be recovered in 



promise is avoided in this situation through the use of 30 clear form, or it requires another bit in the CV to distin- 



gate 28 which prevents instructions in middle chip 26 
from accessing data in upper chip 16 or lower chip 18. 
The code in middle chip 26, therefore, can include low 
level' instructions or operations that are understandable 
by the microprocessor 14. Although the code executes 35 
outside the secure area of the cryptographic module 10', 
four of the UDF commands, 58, 62, 64, and 68 are used 
to manage the code. Furthermore, cryptographic and 
system services are provided to the code via a 'Call* 
interface. 40 

While it is possible to create a UDF that could expose 
a cleartext key, the master key can in no way be com- 
promised. During the execution of a particular UDF 
that involves cryptographic operations, the Kl-Regis- 
ter 80 and/or the K2-Register 82 (which are shown in 45 
FIG. 4 and discussed in greater detail below) will ordi- 
narily contain cleartext cryptographic keys. The keys 
are loaded into the Kl-Register 80 and the K2-Register 
82 using the LDKEY1 instruction and the LDKEY2 
instruction, respectively. The LDKEYx instructions 50 
require the adjacent higher odd numbered save area to 
contain a Control Vector (CV) that will be exclusive- 
OR*d with the master key. The result of the exclusive- 
OR is then used to recover the clear key from the quan- 
tity contained in the specified even numbered save area. 55 
Control vectors are discussed in greater detail in U.S. 
Pat. Nos. 4,993,069, 5,007,089, 5,073,934, 4,850,017, 
4,941,176, 4,918,728, 4,924,514, and 4,924,515, all of 
common assignee with this application. One bit of the 

CV controls usage of the key in the UDF facility. An- 60 from the invoking application is made available to the 



guish which keys can be recovered and which keys 
cannot be recovered using the LDKEYx instructions. 
Those keys which cannot be recovered using the 
LDKEYx instructions can only be used via a chained 
recovery mechanism. 

In another alternate embodiment, a bit in the CV 
indicates whether the key is to be returned to the invok- 
ing UDF or stored in a protected area similar to the 
master key. If the key is to be stored in a protected area, 
the recovered key will be used in subsequent crypto- 
graphic operations on the basis of an address or pointer 
to the key, but the value of the key will not be available 
to the invoking UDF. 

UDF Machine 

The UDF machine 54 is illustrated in greater detail in 
FIG. 4. The drawing is a representation of the function 
of the UDF machine which is implemented by code 
stored in the upper chip 16. The UDF machine 54 in- 
cludes an input/output (I/O) buffer 70, a push/pop 
stack 72, save areas 74, data registers 76 and 78, key 
registers 80 and 82, an operations unit 84, and a count 
register 86. The actual storage areas associated with the 
I/O buffer 70, the stack 72, the save areas 74, the data 
registers 76 and 78, the key registers 80 and 82, the 
operations unit 84, and the count register 86 are in the 
lower chip 18. 

The I/O buffer 70 is used to pass all data and results 
between the invoking application and the UDF. Input 



other bit of the CV controls usage of the key in opera- 
tions performed by code that is loaded into middle chip 
26i A third bit of the CV controls usage of the key in 
normal (non-UDF) operations. 

If the first bit is active, the key is permitted to be used 
in the UDF facility. If the first bit is not active, usage of 
the key in the UDF facility is blocked. If the second bit 
is active, the key is permitted to be used in operations 



65 



UDF by moving it from the I/O buffer 70 into the 
A-Register 76 via one of two instructions, Load A-Reg- 
ister (LAR) or Load A-Register Indirect (LARI). Re- 
sults from the UDF are made available to the invoking 
application by moving them from the B-Register 78 into 
the I/O buffer 70 via one of two instructions, Store 
B-Register (SBR) or Store BrRegister Indirect (SBRI). 
The encryption and decryption instructions, ENCIP 
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and DECIP, get input directly from and store results 0) is on the left and low order byte (byte 7) is on the 
directly to the I/O buffer 70. The I/O buffer 70 is right. A carry, borrow, or shift is propagated byte to 
unique to the UDF machine and can be managed in any byte from right to left, but not out of the eight bytes, 
known manner desired by the UDF programmer. In Within each byte, high order bit (bit 0) is on the left and 
addition, the I/O buffer 70 is battery backed up (not 5 low order bit (bit 7) is on the right, 
shown). Thus, non-volatile data, such as unique keys for _ p Instructions 

UDF use, can be stored there. The loading and destruc- 
tion of such keys can be done using a UDF designed for The set of UDF instructions includes 97 instructions 
such a purpose. The I/O buffer 70 is 4095 bytes long in available for use in creating a UDF. It is contemplated, 
the preferred embodiment. 10 however, that additional UDF instructions may be im- 

The push/pop stack 72 is implemented at the highest plemented. The mnemonic form of each of these in- 
I/O buffer address. The size of the stack 72 is specified structions is given below along with a description of its 
when the UDF Set header is defined at assembly time. function in the preferred embodiment. 
Three stack sizes may be specified: small— 512 bytes, 1. ADDD— Add the contents of the A-Register 76 to 
medium— 1024 bytes, and large— 2048 bytes. The first 15 the contents of the B-Register 78 and store the result in 
512 bytes of the stack 72 are Tree — the space is not the B-Register 78. There are no facilities for detecting 
subtracted from the I/O buffer space. For medium or an overflow condition or the occurrence of a carry 
large stack sizes, the additional space is taken from the value from the high order byte. 
I/O buffer space starting at the highest I/O buffer ad- 2. ANDD— AND the contents of the A-Register 76 
dress. The A-Register 76, B-Register 78, and I-Register 20 to the contents of the B-Register 78 and store the result 
86 as well as the save areas 74 may be pushed onto and in the B-Register 78. 

popped off the stack 72. The stack 72 is initialized when 3. AREG2STK— Move the contents of the A-Regis- 
the UDF Set is loaded and a CLRSTK instruction is ter 76 to the stack 72 at the offset specified in the in- 
provided to reset the Top Of Stack (TOS) pointer to the struction. The A-Register 76 and the TOS pointer are 
highest stack address. 25 not changed. The specified offset is added to the 'origin 

The two data registers, the A-Register 76 and the of the stack'— the lowest address in stack storage. The 
B-Register 78, are used for the manipulation of data. low order three bits of the specified offset are set to 
Both data registers 76 and 78 are eight bytes wide in the X'000' to force the offset to be a multiple of eight bytes, 
preferred embodiment. In general, the A-Register 76 The specified offset is relative to the origin of the stack 
receives the input to the operations unit 84 and the 30 72, not the top of the stack 72. The origin of the stack 72 
B-Register 78 receives the output from the operations depends on the size of the stack 72. For a small stack 72, 
un i t 84. the origin of the stack 72 is at offset X'1000' from the 

The two key registers, the Kl-Register 80 and the start of the I/O buffer 70 and the instruction 
K2-Register 82, are used to hold cryptographic keys for AREG2STK 8 would result in the A-Register 76 being 
the cipher type instructions. Both key registers 80 and 35 stored at X'1008' from the start of the I/O buffer 70. If 
82 are eight bytes wide in the preferred embodiment. the stack 72 is medium, the same instruction stores the 
The LDKEY1 and LDKEY2 instructions are used to A-Register 76 at X'E08' from the start of the I/O buffer 
load cryptographic keys into the Kl-Register 80 and 70 and if the stack 72 is large, it stores the A-Register 76 
the K2-Register 82, respectively. at X'808' from the start of the I/O buffer 70. It is the 

There are sixteen save areas 74 available. Each of the 40 UDF programmer's responsibility to keep track of 
save areas 74 is eight bytes wide in the preferred em- where data is moved to and from the stack 72. 
bodiment. The contents of the A-Register 76, the B- 4. CLRA— Clear the A-Register 76 to all zeroes. 
Register 78, the Kl-Register 80, the K2-Register 82, 5. CLRB — Clear the B-Register 78 to all zeroes, 
and the I-Register 86 can be saved to the save areas 74 6. CLRK1 value— Clear the eight bytes of the Kl- 
via SAVEA, SAVEB, SAVEK1, SAVEK2, and 45 Register 80 to the value specified in the instruction. 
SAVEI instructions, respectively. The contents of the Both nibbles of each byte of the Kl-Register 80 will be 
save areas 74 can be restored to the A-Register 76, the set to the specified value. 

B-Register 78, the Kl-Register 80, the K2-Register 82, 7. CLRK2 value— Clear the eight bytes of the K2- 
and the I-Register 86 via RESTA, RESTB, RESTK1, Register 82 to the value specified in the instruction. 
RESTK2, and RESTI instructions, respectively. Thus, 50 Both nibbles of each byte of the K2-Register 82 will be 
data may be transferred between the various registers set to the specified value. 

and the save areas using the SAVEx and RESTx in- 8. CLRSTK— Reset the TOS pointer to the highest 
structions. Some UDF instructions use dn even/odd stack address. The data contained in the stack 72 is 
pair of save areas 74 to hold arguments. In general, the cleared to all zeroes. 

save areas 74 are used to hold intermediate results in 55 9. DECB— Subtract one from the contents of the 
much the same way a stack might be used. The contents B-Register 78 and store the result in the B-Register 78. 
of the save areas 74 are not cleared upon entering a There are no facilities for detecting an underflow condi- 
UDF nor are they cleared upon exiting a UDF. tion or the occurrence of a borrow value from the high 

There is no 'real* entity corresponding to the opera- order byte. If the B-Register 78 contains all zeroes at the 
tions unit 84, but the term is used to help visualize the 60 start of the instruction, it will contain all Fs at the 
architecture of the UDF machine 54. All of the instruc- completion of the instruction. 

tions; i.e. ANDD, ORR, XORR, are assumed to take 10. DECI— Subtract one- from the contents of the 
place in the operations unit 84. I-Register 86 and store the result in the I-Register 86. 

The count register, the I-Register 86, is used gener- There are no facilities for detecting an underflow condi- 
ally as a loop counter. The I-Register 86 is two bytes 65 tion or the occurrence of a borrow value from the high 
wide in the preferred embodiment. order byte. If the I-Register 86 contains all zeroes at the 

The data in the data paths and registers is treated as start of the instruction, it will contain all Fs at the 
eight unsigned characters (bytes). High order byte (byte completion of the instruction. 
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11. DECIP Key, SA— • Perform a Data Encryption the instruction. Unsigned integer arithmetic is used and 
Algorithm Cipher Block Chaining (DEA CBC) mode any overflow is lost. The same save area 74 may be 
decryption operation using the key register (Kl-Regis- specified for both operands. 

ter 80 or K2-Register 82) specified in the instruction. 17. EMKKI SA— Encipher the key from the Kl- 

'SA 1 specifies an even numbered save area 74. Permissi- 5 Register 80 into the save area 74 specified in the instruc- 

ble values of 'SA' are 0, 2, 4, and 6 in the preferred tion. *SA' specifies an even numbered save area 74. 

embodiment. The rightmost two bytes of the specified Permissible values of 'SA' are 8, 10, 12, and 14 in the 

even numbered save area 74 contain a displacement preferred embodiment. The specified even numbered 

(0DDD) into the I/O buffer 70 to byte 0 of the input save area 74 receives the quantity e*KM.CVl(Kl). This 

ciphertext to be deciphered. The rightmost two bytes of 10 quantity is the triple encipherment (ede) of Kl under 

the adjacent higher odd numbered save area 74 contain the control vector variant (CV1) of key KM. The adja- 

a displacement (Oddd) into the I/O buffer 70 where byte cent higher odd numbered save area 74 contains the 

0 of the resultant cleartext is to be stored. The number quantity CV1. Successful completion of the instruction 

of eight byte blocks to be deciphered is contained in the results in the enciphered key being stored in the speci- 

I-Register 86. The B-Register 78 is assumed to contain 15 fied even numbered save area 74. 

the Initial Chaining Vector (ICV) at the start of the 18. EMKK2 SA— Encipher the key from the K2- 

instruction. Load the A-Register 76 with the eight bytes Register 82 into the save area 74 specified in the instruc- 

of data starting at I/O buffer + ODDD, using ODDD tion. 'SA* specifies an even numbered save area 74. 

from the even numbered save area 74. Increment the Permissible values of 'SA* are 8, 10, 12, and 14 in the 

contents of the even numbered save area 74 by eight so 20 preferred embodiment. The specified even numbered 

that it points to the next eight bytes of data. Decipher save area 74 receives the quantity e*KM.CVl(K2). This 

the contents of the A-Register 76 and XOR the result quantity is the triple encipherment (ede) of K2 under 

into the B-Register 78. Store the resultant cleartext in the control vector variant (CV1) of key KM. The adja- 

the B-Register 78 at I/O buffer + Oddd, using Oddd from cent higher odd numbered save area 74 contains the 

the odd numbered save area 74. Increment the contents 25 quantity CV1. Successful completion of the instruction 

of the odd numbered save area 74 by eight. Decrement results in the enciphered key being stored in the speci- 

the contents of the I-Register and repeat the process fied even numbered save area 74. 

using the previous input instead of the ICV to recover 19. ENCIP Key, SA— Perform a Data Encryption 

the cleartext until the I-Register 86 is equal to zero. Algorithm Cipher Block Chaining (DEA CBC) mode 

12. DECODE Key, In, Out— Perform a Data En- 30 encryption operation using the key register (Kl-Regis- 
cryption Algorithm Electronic Code Book (DEA ter 80 or K2-Register 82) specified in the instruction. 
ECB) mode decryption operation using the registers 'SA' specifies an even numbered save area 74. Permissi- 
specified in the instruction. 'Key' must be the Kl-Regis- ble values of 'SA* are 0, 2, 4, and 6 in the preferred 
ter 80 or the K2-Register 82. 'In* may be either the embodiment. The rightmost two bytes of the specified 
A-Register 76 or the B-Register 78 and 'Out* may be 35 even numbered save area 74 contain a displacement 
either the A-Register 76 or the B-Register 78. The same (ODDD) into the I/O buffer 70 to byte 0 of the input 
register may be specified for both 'In* and 'Out.' Addi- cleartext to be enciphered. The rightmost two bytes of 
tionally, the instruction could be expanded by known the adjacent higher odd numbered save area 74 contain 
methods to allow 'Key* to be the A-Register 76 or the a displacement (Oddd) into the I/O buffer 70 where byte 
B-Register 78. 40 0 of the resultant ciphertext is to be stored. The number 

13. DECS A S A— Subtract one from the contents of of eight byte blocks to be enciphered is contained in the 
the save area 74 specified in the instruction and store the I-Register 86. The B-Register 78 is assumed to contain 
result in the specified save area 74. There are no facili- the Initial Chaining Vector (ICV) at the start of the 
ties for detecting an underflow condition or the occur- instruction. Load the A-Register 76 with the eight bytes 
renceofaborrow value from the high order byte. If the 45 of data starting at I/O buffer +0DDD, using ODDD 
specified save area 74 contains all zeroes at the start of from the even numbered save area 74. Increment the 
the instruction, it will contain all Ps at the completion contents of the even numbered save area 74 by eight so 
of the instruction. that it points to the next eight bytes of data. XOR the 

14. DEC2HEX, SAi, SAj— Convert the contents of contents of the B-Register 78 into the A-Register 76 and 
the first save area 74 specified in the instruction into a 50 encipher the contents of the A-Register 76. Store the 
hexadecimal value and store the result int he second resultant ciphertext in the B-Register 78 at I/O buf- 
save area 74 specified in the instruction. The first speci- fer+Oddd, using Oddd from the odd numbered save 
fled save area 74 is assumed to contain a binary coded area 74. Increment the contents of the odd numbered 
decimal value. The second specified save area 74 is save area 74 by eight. Decrement the contents of the 
cleared to all zeroes at the start of the instruction. The 55 I-Register 86 and repeat the process using the previous 
same save area 74 may be specified for both operands. result instead of the ICV to encipher the cleartext until 

15. DEFCON SA, value— Right justify the value the I-Register 86 is equal to zero. 

specified in the instruction into the save area 74 speci- 20. ENCODE Key, In, Out— Perform a Data En- 

fied in the instruction. The specified value is assumed to cryption Algorithm Electronic Code Book (DEA 

be a hexadecimal value. The specified save area 74 is 60 ECB) mode encryption 

cleared to all zeroes at the start of the instruction. operation using the registers specified in the instruc- 

16. DIVISA SAi, SAj— Divide the rightmost four tion. 'Key 1 must be the Kl-Register 80 or the ^Regis- 
bytes of the first save area 74 specified in the instruction ter 82. 'In' may be either the A-Register 76 or the B- 
into the eight bytes of the second save area 74 specified Register 78 and 'Out* may be either the A-Register 76 
in the instruction. Store the resulting four byte quotient 65 or the B-Register 78. The same register may be specified 
in the B-Register 78. Store the resulting remainder in for both 'In* and 'Out/ Additionally, the instruction 
the leftmost four bytes of the first specified save area 74. could be expanded by known methods to allow 'Key' to 
The B-Register 78 is cleared to all zeroes at the start of be the A-Register 76 or the B-Register 78. 
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21 EXIT— Exit the currently executing UDF. 37. JALTB jump target— Jump if the A-Register 76 is 

22 GRNB— Generate a random number and store it less than the B-Register 78. If the A-Register 76 is less 
in the B-Register 78. than the B-Register 78, add the displacement field to the 

23. ORNKl-Generate a random number and store it current instruction counter. If not, execute the next 
in the KI-Register 80 5 sequential instruction. 

24. GRNK2-Oenerate a random number and store it 38. JALEB jump target-Jump if- the A-Register 76 is 
in the K2 Reeister 82 less than or equal to the B-Register 78. If the A-Register 

25 GRNSA SA-Generate a random number and 7« is less than or equal to the B-Register 78, add the 
store it in the save area 74 specified in the instruction. displacement field to the current instruction counter. If 

26. HEX2DEC SAi, SAj-Convert the contents of "> not, execute the next sequential 

the first save area 74 specified in the instruction into a 39 JAEB J^Pj^VSl ReSsler T6k££ 
binary coded decima. valued store ^SS^^^SSS^^ 
second save area 74 specified in the instruction. The lu " lc , ' nto<r If ^ - w „tP the next 

firstspecinedsavearea74is a ssumedtocontainahexa. ^."JSS^ 
decimal value. The second specified save area 74 is « ^^G^ 

clearedtoallzeroesatthestartoft^ is grelto th J or^ual to the B-Register 78. If the 

decimal numbers are truncated "J^ ™ ^j^* A-Register 76 is greyer than or equal to the B-Register 
same save area 74 may be specified for both operands. * displacement field to the current instruction 

27. INCB-Add one to the contents of the B-Register Jf ^ next ^ instruction . 
78 and store the result in the B-Register 78. There are 41 JAGfi target-Jump if the A-Register 76 is 
no facilities for detecting an overflow condition i or the er than ^ B . Register 78 . If the A-Register 76 is 
occurrence of a carry value from the high order byte. If gr ^ the B . Register 78f add the displacement 
the B-Register 78 contains all Ps at the start of the f|dd tQ the cujTent instruction COU nter. If not, execute 
instruction, it will contain all zeroes at the completion 2$ the next g^^^ai instruction. 

of the instruction. 42. j ANEB jump target— Jump if the A-Register 76 

28. INCI— Add one to the contents of the I-Register [$ n<Jt equal to the B _ Re gister 78. If the A-Register 76 is 
86 and store the result in the I-Register 86. There are no n(Jt equaJ tQ the B-Register 78, add the displacement 
facilities for detecting an overflow condition or the field tQ tne current instruction counter. If not, execute 
occurrence of a carry value from the high order byte. If 3Q the next sequential instruction. 

the I-Register 86 contains all Fs at the start of the in- 43 jj NZ j ump target— Jump if the I-Register 86 is 
struction, it will contain all zeroes at the completion of not equa j t0 zer0 jf ^e I-Register 86 is not equal to 
the instruction. zero, add the displacement field to the current instruc- 

29. INCSA SA— Add one to the contents of the save t j on counter. If not, execute the next sequential instruc- 
area 74 specified in the instruction and store the result in 35 t j on 

the specified save area 74. There are no facilities for 44 jsaZ SA, jump target— Jump if the save area 74 
detecting an overflow condition or the occurrence of a specified in the instruction is equal to zero. If the speci- 
carry value from the high order byte. If the specified f iec j save area 74 is equal to zero, add the displacement 
save area 74 contains all F's at the start of the instruc- f ie j d t0 t h e current instruction counter. If not, execute 
tion, it will contain all zeroes at the completion of the 49 tne nex t sequential instruction. 

instruction. 45. JSANZ SA, jump target— Jump if the save area 

30. INCUDF UDFname, EXT— Add the UDF spec- 74 specified in the instruction is not equal to zero. If the 
ified in the instruction to the UDF Set specified in the specified save area 74 is not equal to zero, add the dis- 
preceding UDFSET instruction. placement field to the current instruction counter. If 

31. JUMP jump target— Unconditional jump. Add 45 n ot, execute the next sequential instruction. 

the displacement field to the current instruction 46. LAR SA — Load the A-Register 76 from the I/O 
counter. buffer 70. The rightmost three nibbles of the save area 

32. JUMPL jump target— Unconditional long jump. 74 specified in the instruction contain a displacement 
Add the displacement field to the current instruction (DDD) into the I/O buffer 70 to byte 0 of an eight byte 
counter. Used for a long (+/-512 bytes) jump. 50 field. Load the number of bytes specified by the I-Regis- 

33. JAZ jump target— Jump if the A-Register 76 is ter 86 from the I/O buffer 70 into the A-Register 76. 
equal to zero. If the A-Register 76 is equal to zero, add The bytes are right justified into the A-Register 76. The 
the displacement field to the current instruction A-Register 76 is cleared to all zeroes at the start of the 
counter. If not, execute the next sequential instruction. instruction. If the I-Register 86 is zero at the start of the 

34. JBZ jump target— Jump if the B-Register 78 is 55 instruction, no bytes are moved. If the I-Register 86 is 
equal to zero. If the B-Register 78 is equal to zero, add greater than eight at the start of the instruction, eight 
the displacement field to the current instruction bytes are moved. If the I-Register 86 is less than eight at 
counter. If not, execute the next sequential instruction. the start of the instruction, the bytes starting at byte 0 

35. JANZ jump target— Jump if the A-Register 76 is (leftmost) of the eight byte field are skipped over and 
not equal to zero. If the A-Register 76 is not equal to 60 the next 'I-Register' bytes are loaded right justified 
zero, add the displacement field to the current instruc- from the I/O buffer 70 into the A-Register 76. 

tion counter. If not, execute the next sequential instruc- 47. LARI SA— Load the A-Register 76 from the I/O 
t j on . buffer 70. The rightmost three nibbles of the save area 

36. JBNZ jump target— Jump if the B-Register 78 is 74 specified in the instruction contain a first displace- 
not equal to zero. If the B-Register 78 is not equal to 65 ment (DDD) into the I/O buffer 70 to a second dis- 
zero, add the displacement field to the current instruc- placement (ddd). Use the second displacement (ddd) to 
tion counter. If not, execute the next sequential instruc- locate byte 0 of an eight byte field. Load the number of 
lion bytes specified by the I-Register 86 from the I/O buffer 
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70 into the A-Register 76. The bytes are right justified 60. PADJSA SA— Odd parity adjust the contents of 
into the A-Register 76. The A-Register 76 is cleared to the save area 74 specified in the instruction, 
all zeroes at the start of the instruction. If the I-Register 61. POP A— Move the eight bytes of data found at the 
86 is zero at the start of the instruction, no bytes are current TOS location to the A-Register 76. The initial . 

moved. If the I-Register 86 is greater than eight at the 5 contents of the A-Register 76 are lost. Increment the 
start of the instruction, eight bytes are moved. If the current TOS by eight. 

I-Register is less than eight at the start of the instruc- 62. POPB— Move the eight bytes of data found at the 
tion, the bytes starting at byte 0 (leftmost) of the eight current TOS location to the B-Register 78. The initial 
byte field are skipped over and the next 'I-Register 1 contents of the B-Register 78 are lost. Increment the 

bytes are loaded right justified from the I/O bufTer 70 »> current TOS by eight. 

into the A-Register 76. 63 - POPI— Move the two bytes of data found at the 

48. LDIRI ifield— Load the contents of the immedi- current TOS location to the I-Register 86. The initial 
ate field specified in the instruction into the 1-Register contents of the I-Register 86 are lost. A total of eight 
g$ bytes are popped off the stack 72. The leftmost six bytes 

49. LDKEY1 SA-Load the key from the save area 15 arc discarded. Increment the current TOS by eight. 
74 specified in the instruction into the Kl-Register 80. <*■ POPSA j?*- Move ih * c !& hx of * ata f ™ n * 
«SA' specifies an even numbered save area 74. Permissi- at * e current TOS location to the save area 74 specified 
ble values of 'SA' are 8, 10, 12, and 14 in the preferred ™ the ""traction . The initial contents of the specified 
embodiment. The even numbered save area 74 contains «™ *"* 74 «* lost Increment current TOS * 
the quantity e*KM.CVl(Kl). This quantity is the triple 20 ^Jl*' 0 „ A w . . . . rJ * r j • 
encipherment (ede) of Kl under the control vecfor ^Tnl^V^^Z 
variant (CV1) of key KM. The adjacent higher odd the A.Repster 76 to the current TOS location. The 

numbered save area 74 contains the Quantity CV1. Sue- ^ ^^1"* "* 

- . - . - . . . . . ^ . * . . Decrement the current TOS by eight. 

cessfiU completion of the mstrucUon results m the clear 2$ ^ PUSH B-Move the eight b£es of data found in 

In t n r?J°rfv e , c a i V \ the B-Register 78 to the current TOS location. The 

50. LDKEY2 SA Load the key from the save area ^ Qf ^ B . Re ^ ster 7g are not chan d< 

74 specified in the instruction into the K2-Register 82. Decrement the current TOS by eight. 
'SA specifies an even numbered save area 74. Permissi- 6? PUSH i_Move the two bytes of data found in the 
ble values of ;SA' are 8, 10 12, and 14 in the preferred M ,. Regisler 86 t0 the current TOS location. The initial 
embodiment. The even numbered save area 74 contains comems of the j. Rcgirtcr 86 are not changed. Six bytes 
the quantity e*KM.CVl(K2). This quantity is the triple of 2eroes are pushed on ^ left side Decreme nt the 
encipherment (ede) of K2 under the control vector current TOS by eight. 

variant (CV1) of key KM. The adjacent higher odd 68 PUSH SA SA— Move the eight bytes of data 
numbered save area 74 contains the quantity CV1. Sue- 35 found in the savearea 74 specified in the instruction to 
cessful completion of the instruction results in the clear the current TOS locat j on . Th e initial contents of the 
key being loaded into the K2-Register 82. specified save area 74 are not changed. Decrement the 

5 1 . MOVEAB— Move the contents of the A-Register current TOS by eight. 

76 to the B-Register 78. The A-Register 76 is not 69. RESTA SA— Move the eight bytes of data from 
changed. 40 the area 74 specified in the instruction to the A- 

52. MOVEIOB SAs, SAt— Move the number of Register 76. 

bytes specified by the I-Register 86 from the I/O bufTer 70 , RESTB SA— Move the eight bytes of data from 
source location specified in the source save area 74 to the area 74 specified in the instruction to the B- 
the I/O buffer target location specified in the target Register 78. 

save area 74. The source and target displacements are 45 71, RESTI S A— Move the rightmost two bytes of 
the right justified two bytes of the respective save areas data from the save area 74 specified in the instruction to 
74. the I-Register 86. 

53. MULTSA SAi, SAj— Multiply the rightmost four 72, RESTK1 SA— Move the eight bytes of data from 
bytes of the save areas 74 specified in the instruction the save area 74 specified in the instruction to the Kl- 
together and store the eight byte result in the B-Register 50 Register 80. 

78.. The B-Register 78 is cleared to all zeroes at the start 73. RESTK2 S A— Move the eight bytes of data from 
of the instruction. Unsigned integer arithmetic is used the save area 74 specified in the instruction to the K2- 
and any overflow is lost. The same save area 74 may be Register 82. 

specified for both operands. 74. REVLOBA— Interchange the two low order 

54. NOOP— No operation is performed. The UDF 55 (rightmost) bytes in the A-Register 76. The other bytes 
machine is not changed. This instruction is a place in the A-Register 76 are not changed. 

holder for debug and other uses. 75. RUM— Replace under mask. Use the rightmost 

55. NOTB— Complement the contents of the B-Reg- two bytes in the A-Register 76 as a bit mask for each of 
ister 78 and store the result in the B-Register 78. the nibbles in the B-Register 78. For each bit in the 

56. ORR— OR the contents of the A-Register 76 to 60 A-Register 76 that is equal to one, replace the corre- 
the contents of the B-Register 78 and store the result in spending nibble in the B-Register 7 with the leftmost 
the B-Register 78. nibble in the A-Register 76. 

57. PADJB— Odd parity adjust the contents of the 76. SAVEA SA— Move the eight bytes of data A- 
B-Register 78. Register 76 to the save area 74 specified in the instruc- 

58. PADJK1— Odd parity adjust the contents of the 65 tion. 

Kl-Register 80. 77. SAVEB SA— Move the eight bytes of data from 

59. PADJK2 — Odd parity adjust the contents of the the B-Register 78 to the save area 74 specified in the 
K2-Register 82. instruction. 
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78. SA VEI SA— Move the two bytes of data from X'E08' from the start of the I/O buffer 70 in the A-Reg- 
the I-Register 86 to the rightmost two bytes of the save ister 76 and if the stack 72 is large, it stores the eight 
area 74 specified in the instruction. The leftmost six bytes starting at X'808' from the start of the I/O buffer 
bytes of the specified save area 74 are cleared to all 70 in the A-Register 76. It is the UDF programmer's 
2eroe s. 5 responsibility to keep track of where data is moved to 

79. SAVEK1 SA— Move the eight bytes of data from and from the stack 72. 

the Kl-Register 80 to the save area 74 specified in the 86. SUBB— Subtract the contents of the A-Register 

instruction. 76 from the contents of the B-Register 78 and store the 

80. SAVEK2 SA— Move the eight bytes of data from result in the B-Register 78. There are no facilities for 
the K2-Register 82 to the save area 74 specified in the 10 detecting an underflow condition or the occurrence of 
instruction. a borrow value from the high order byte. 

81. SBR SA— Store the B-Register 78 to the I/O 87. SWAP— Interchange the contents of the A-Reg- 
buffer 70. The rightmost three nibbles of the save area ister 76 and the contents of the B-Register 78. 

74 specified in the instruction contain a displacement 88. UCALL local label— Provides a local CALL to 
(DDD) into the I/O buffer 70 to byte 0 of an eight byte 15 be used within a UDF. This removes the need to have 
field. Store the number of bytes specified by the I-Reg- the called routine contain a UDF Header. This saves 32 
ister 86 from the B-Register 78 into the eight byte field bytes of storage space, but the specified local label is not 
in the I/O buffer 70. The bytes are right justified into callable by an external routine, 
the eight byte field in the I/O buffer 70. If the I-Register 89. UDF UDFname— Invoke the UDF referenced by 
86 is zero at the start of the instruction, no bytes are 20 the UDF Reference ID field as a subroutine. UDFname 
moved. If the I-Register 86 is greater than eight at the can also be invoked by an external call, 
start of the instruction, eight bytes are moved. If the 90. UDFBEG UDFName, Ext, AuthLevel, MaxOut, 
I-Register 86 is less than eight at the start of the instruc- <UserComment>— Start a UDF definition. Build the 
tion, the bytes starting at byte 0 (leftmost) of the eight UDF Header. The length of the UDF Header is 32 
byte field are skipped over and the next 'I-Register' 25 bytes. The name of the UDF must be specified. The 
bytes are stored right justified from the B-Register 78 name can be up to eight characters long. Imbedded 
into the eight byte field in the I/O buffer 70. blanks are not allowed. If the name is less than eight 

82. SBRI SA— Store the B-Register 78 to the I/O characters long, it is padded on the right with blanks, 
buffer 70. The rightmost three nibbles of the save area The name must be the same name that is used in the 
74 specified in the instruction contain a first displace- 30 INCUDF instruction. The name need not be the name 
ment (DDD) into the I/O buffer 70 to a second dis- of the object file that contains the UDF code. The name 
placement (ddd). Use the second displacement (ddd) to • will be entered into the UDF Header and will be used 
locate byte 0 of an eight byte field. Store the number of for all references to the UDF. In addition to the UDF- 
bytes specified by the 1-Register 86 from the B-Register Name field, there is a three character extension field. If 
78 into the eight byte field in the I/O buffer 70. The 35 the extension is less than three characters long, it is 
bytes are right justified into the eight byte field in the padded on the right with blanks. If an extension is speci- 
I/O buffer 70. If the 1-Register 86 is zero at the start of fied, it must be the same extension that is used in the 
the instruction, no bytes are moved. If the I-Register 86 INCUDF instruction. The three byte extension field is 
is greater than eight at the start of the instruction, eight concatenated to the right of the eight byte UDFName 
bytes are moved. If the I-Register 86 is less than eight at 40 field to form an eleven byte internal name for the UDF. 
the start of the instruction, the bytes starting at byte 0 These eleven bytes are used to invoke the UDF. If the 
(leftmost) of the eight byte field are skipped over and extension is omitted, the comma (,) must be supplied, 
the next 'I-Register* bytes are stored right justified from The default extension is three blanks in the preferred 
the B-Register 78 into the eight byte field in the I/O embodiment. The authority level required to execute 
buffer 70. 45 this UDF may also be specified. If the authority level is 

83. SETEND — Mark the end of a UDF Set defini- omitted, the comma (,) must be supplied. The default 
t i oni authority level is 0 in the preferred embodiment. The 

84. SHIFTT +/-N— Shift the contents of the B- maximum authority level is 255 in the preferred embodi- 
Register 78 right (+) or left (-) N positions as specified ment. The maximum number of bytes that may be re- 
in the instruction. Zero bits are shifted in on the left or 50 turned by the UDF may be specified as 'MaxOut.' •Max- 
right and the bits shifted out on the right or left are lost. Out' may range from 0 to 4095 in the preferred embodi- 
The maximum shift in either direction is 63. ment. A 'MaxOut* value of 0 means that the UDF can 

85. STK2AREG offset— Move the eight bytes in the return no output data. A 'MaxOut* value of 374 means 
stack 72 starting at the offset specified in the instruction that the maximum number of bytes that will be returned 
to the A-Register 76. The stack 72 and the TOS pointer 55 to the invoking application is 374. If the 'MaxOut* value 
are .not changed. The specified offset is added to the is omitted, the default 'MaxOut* value is 256 in the pre- 
'origin of the stack'— the lowest address in stack stor- ferred embodiment. The 'MaxOut' value has meaning 
age. The low order three bits of the specified offset are for the UDF that receives control when execution be- 
set to X'000' to force the offset to be a multiple of eight gins. The number of bytes that are expected to be re- 
bytes. The specified offset is relative to the origin of the 60 turned from the UDF is indicated when the UDF is 
stack 72, not the top of the stack 72. The origin of the invoked. This expected out value is compared to the 
stack 72 depends on the size of the stack 72. For a small 'MaxOut' value. If the 'MaxOut' value is less than the 
stack 72, the origin of the stack 72 is at offset X'1000' expected out value, execution does not start. The op- 
from the start of the I/O buffer 70 and the instruction tional twelve byte user comment must be enclosed in 
STK2AREG 8 would result in the eight bytes starting 65 pointy brackets as shown. This field is not checked in 
at X'1008' from the start of the I/O buffer 70 being any way and may contain any imbedded characters 
stored in the A-Register 76. If the stack 72 is medium, with the exception of the pointy brackets used to delimit 
the same instruction stores the eight bytes starting at the field. 
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91. UDFEND— Mark the end of a UDF definition. 

92. UDFSET UDFSetName, Ext, StackSize, < User- 
Comment— Start a UDF Set definition. Build the 
UDF Set Header. The length of the UDF Set header is 
32 bytes. The name of the UDF Set must be specified. 
The name can be up to eight characters long. Imbedded 
blanks are not allowed. If the name is less than eight 
characters long, it is padded on the right with blanks. 
The name need not be the name of the file that contains 
the UDF Set code. The name will be entered into the 
UDF Set Header and will be used for all references to 
the UDF Set. In addition to the UDFSetName field, 
there is a three character extension field. If the exten- 
sion is less than three characters long, it is padded on the 
right with blanks. The three byte extension field is con- 
catenated to the right of the eight byte UDFSetName 
field to form an eleven byte internal name for the UDF 
Set. These eleven bytes are used for all references to the 
UDF Set. The UDFSetName and extension are used by 



10 



15 



tion number (PIN) verification algorithm, alteration of 
a cryptographic key prior to use, special functions to 
accommodate the intersection of dissimilar crypto- 
graphic regions. The next step is for the UDF program- 
mer to select particular instructions from the set of 
UDF instructions and arrange them in a sequence ap- 
propriate to implement the desired function of the 
UDF. This second step is very much like writing any 
other program. The length of the data input to the UDF 
and the length of the result output from the UDF are 
limited to 4095 bytes in the preferred embodiment, but 
can be expanded by known methods. 

A UDF can be created using any editor 106 the UDF 
programmer chooses. The UDF input file 108 that is 
created is assembled. In the preferred embodiment, the 
UDF input file 108 is assembled using a macroassembler 
110, such as the IBM Macro Assembler/2 tm or the 
Microsoft Macro Assembler, along with an include file 
of macros 112. The macro include file 112 contains the 



coded bytes understandable by the interpreter micro- 
code that implements the UDF machine. The assembler 
110 accepts the mnemonic form of the UDF instruc- 
tions as a text input file. In general, an entire UDF is 
contained in a single text file. The UDF input file 108 is 
checked for validity and the UDF instructions are as- 
sembled into a UDF object file 114. Each of the individ- 
ual UDFs is assembled in this way. The format of an 
individual UDF after it has been assembled is described 
in Chart 1, below. 

Chart 1 

Format of an individual UDF 



R ID 


UDFNAMEb 


EXT 


n n n n 


V V 


a a 


m m ri m 


rsvd 


USERCOMMENTb 



USER 



DEFINED FUNCTION 
CODE 



F0FFFF 



the Register, Load, Verify, Delete, and Query com- 20 code required to translate the UDF instructions into the 
mands. If the extension is omitted, the comma (,) must 
be supplied. The default extension is three blanks in the 
preferred embodiment. The stack size to be used with 
the UDF Set may also be specified. If the stack size is 
omitted, the comma (,) must be supplied. The default 25 
stack size is small (512 bytes) in the preferred embodi- 
ment. Other stack size choices are medium (1024 bytes) 
and large (2048 bytes). The first 512 bytes of stack space 
are located above the I/O buffer used for the UDFs. 
Stack space above 512 bytes is taken; from the I/O 30 I 
buffer. The optional sixteen byte user comment must be 
enclosed in pointy brackets as shown. This field is not 
checked in any way and may contain any imbedded 
characters with the exception of the pointy brackets 
used to delimit the field. 35 

93. URET— Provides a return from a local CALL to 
be used within a UDF. This removes the need to have 
the called routine specified by the UDF Header. 

94. XNIB— Use each nibble in the B-Register 78 as an 
index into the A-Register 76. Replace each nibble in the 40 
B-Register 78 with the nibble in the A-Register 76 
found at the indexed location. 

95. XORR— XOR the contents of the A-Register 76 
to the contents of the B-Register 78 and store the result 
in the B-Register 78. 45 

96. XORK1 SA— XOR the contents of the save area 
74 specified in the instruction to the contents of the 
Kl-Register 80 and store the result in the Kl-Register 
80. 

97. XORK2 SA— XOR the contents of the save area 50 
74 specified in the instruction to the contents of the 
K2-Register 82 and store the result in the K2-Register 
82. 

While it is contemplated that a variety of op codes 
could be assigned to the UDF instructions, in the pre- 55 
ferred embodiment, the op codes for ADDD, ANDD, 
EXIT, ORR, and SUBB are X'BB,' X'B9,' X'FO,' X'B8/ 
and X'BC/ respectively. 

Preparing UDFs 

The UDF development process is illustrated in FIG. 
5. This process is described in detail in this section and 
in the next section on managing UDFs and external 
objects. 

Using the set of UDF instructions, a UDF program- 
mer can create a UDF in step 104. The first step is for 
the UDF programmer to decide what the UDF will be 
required to do, e.g., a proprietary personal identifies- 



RID Reference ID ■ This number is assigned by the 
linker when the UDF Set is built. It is used to invoke the 
UDF when it is called as a subroutine from another UDF. 

UDFNAME = Alphanumeric name or the UDF. The name may 
have a maximum of eight characters. If the name is less 
than eight characters, it is padded with blanks. This name 
is used when the UDF is invoked. 

EXT = Three character extension to the UDFNAME. If 

the extension is less than three characters, it is padded 

with blanks. This extension is used when the UDF is invoked. 

nnnn = Total number of bytes in the UDF. 

vv =s Version number of the UDF Macro Include File used 
to assemble the UDF. 



aa = Authority level required to execute the UDF. The 
user's authority level must be greater than or equal to 
60 this authority level. 

« Total number of bytes permitted to be output by 
the UDF. This number is enforced when the UDF execution ends. 

USERCOMMENT » Twelve character field for any user 
65 information. If the usercomment is less than twelve 
characters, it is padded with blanks. The usercomment is 
not checked in any way. 
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Most of these fields are set by the UDFBEG instruc- 
tion. 

A UDF Set is created in much the same way as an 
.individual UDF. Using the INCUDF instruction, the 
UDF programmer specifies the UDFs to be included in 5 
the UDF Set. The first object file must have the UDF- 
SET instruction in it. The remainder of the object files, 
which contain the individual UDFs, can be specified in 
any sequence. The UDF Set defmition file that is cre- 
ated is then assembled and linked together with the 10 
previously assembled individual UDFs into a single 
UDF Set. The UDF Set cannot exceed 4096 bytes in 
length in the preferred embodiment, but can be ex- 
panded by known methods. A linker 116, such as the 
IBM Macro Assembler/2 Linker, is used to link the 15 
UDF Set 118. The linker 116 collects the individual 
UDFs into the UDF Set 118. The format of a UDF Set 
after it has been assembled and linked is described in 
Chart 2, below. 

Chart 2 

Format of a UDF Set 



NN SETNAMEb EXT nnnn vv ss 



USERCOMMENTbbbbb 



IA01 



IA0S IA09 



1A02 



IA03 



1A04 



IA05 



IA06 



1AL 



1A07 



USER DEFINED FUNCTION 01 
CODE 

FOFFFF 



USER DEFINED FUNCTION 02 
CODE 



FFFF 



USER DEFINED FUNCTION Last 
CODE 



FFFF 



NN » Number of UDFs in the UDF Set. 

SETNAME = Alphanumeric name of the UDF Set. The name 
may have a maximum of eight characters. If the name » 
less than eight characters, it is padded with blanks. 

EXT = Three character extension to the SETNAME. If 
the extension is less than three characters, it is padded 
with blanks. 

nnnn = Total number of bytes in the UDF Set. 

w » Version number of the UDF Macro Include File used 
to assemble and link the UDF Set. 

ss = Stack size: 0 «* small, 1 = medium, 2 = large 

USER COMMENT = Sixteen character Held for any user 
information. If the usercomment is less than sixteen 
characters, it is padded with blanks. The usercomment is 
not checked in any way. 

lAx = Initial address for UDF x 



20 



25 



30 



35 



40 



45 



50 



55 
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65 



Most of these fields are set by the UDFSET instruction. 
A utility program 120 removes the EXE header (the 
first 512 bytes) from the UDF Set 118 produced by the 



assembler 110 and the linker 116. The result is an exe- 
cutable UDF Set 122. 

The executable UDF Set 122 may be used as input to 
a UDF simulator 124 to verify the operation of the 
individual UDFs. The UDF simulator 124 accepts the 
output of the UDF linker step and allows the UDF 
programmer to simulate the execution of the UDF and 
trace the results generated at each step. Thus, the UDF 
simulator 124 provides a means to assist the UDF pro- 
grammer in debugging the UDF. It is well known to 
one of ordinary skill in the art to provide a simulator 
having the software to verify the operation of a UDF 
and assist in the debugging of a UDF. The UDF simula- 
tor screen displays the disassembled UDF, the registers, 
the save areas, etc. of FIG. 4. Each time 'Enter 1 is 
pressed, the current instruction is executed and the 
display screen is updated. There are several options to 
choose with the UDF simulator display screen. One 
option toggles the display screen between the save area 
74 and the stack 72. Another option ('Update 1 ) allows 
the UDF programmer to modify the data on the display 
screen. The save areas 74, the registers, and the I/O 
buffer 70 can be changed in this way. 'Update* can be 
entered anytime the UDF simulator is waiting for input 
while doing UDF simulation. A third option ('Go') 
causes the current UDF to run to the next 'EXIT in- 
struction or until CTRL-BREAK is pressed. When the 
end is reached, the UDF programmer is taken to a 
display screen that permits the programmer to specify a 
file name into which the current I/O buffer 70 can be 
saved for future use. The UDF programmer could also 
use this method to get the first I/O buffer 70 image to be 
loaded. This display screen appears only at the comple- 
tion of a UDF. 

When a UDF is invoked, up to 4095 bytes of data can 
be passed into the UDF from the invoking application. 
The number of bytes that are actually passed in is speci- 
fied at the time the UDF is invoked. When the UDF 
receives control, the I/O buffer 70 contains the data to 
be passed into the UDF. All data to be processed by the 
UDF machine has to be moved from the I/O buffer 70 
to the A-Register 76. There are two instructions to 
move data from the I/O buffer 70 to the A-Register, 
LAR and LARI. If the input data is always at fixed 
locations in the I/O buffer 70, the UDF programmer 
can use the LAR instruction to move the data from the 
location in the I/O buffer 70 specified by the contents of 
the save area 74 to the A-Register 76. The DEFCON 
instruction can be used to setup the save area 74 with 
the location of the input data in the I/O buffer 70. If the 
input data can be at different locations in the I/O buffer 
70, the UDF programmer can use the LARI instruction 
to move the data from an indirect location in the I/O 
buffer 70 to the A-Register 76. 

When a UDF has completed executing, up to 4095 
bytes of data can be returned from the UDF to the 
invoking application. The number of bytes that are 
actually returned is specified at the time the UDF is 
invoked. When the UDF relinquishes control, the con- 
tents of the I/O buffer 70 are returned to the invoking 
application. Thus, the UDF, programmer must ensure 
that the data to be returned is in the I/O buffer 70 prior 
to exiting the UDF. There are two instructions to move 
data from the B-Register 78 to the I/O buffer 70, SBR 
and SBRI. If the output data is always at fixed locations 
in the I/O buffer 70, the UDF programmer can use the 
SBR instruction to move the data from the B-Register 
78 to the location in the I/O buffer 70 specified by the 
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contents of the save area 74. The DEFCON instruction 
can be used to setup the save area 74 with the desired 
location of the output data in the I/O buffer 70. If the 
output data can be at different locations in the I/O 
buffer 70, the UDF programmer can use the SBRI in- 
struction to move data from the B-Register 78 to an 
indirect location in the I/O buffer 70. 

Cryptographic keys can also be used in a UDF. Cryp-. 
tographic keys can either be generated for use in the 
UDF or operational forms of the keys can be used to 
complete the processing. The LDKEY1 and LDKEY2 
instructions can be used to recover clear keys into the 
Kl-Register 80 and the K2-Register 82, respectively. 
Generated keys can be put into operational form by 
using the EMKK1 and EMKK2 instructions. There are 
four instructions available for cryptographic processing 
in the UDF, ENCIP, DECIP, ENCODE, and DE- 
CODE. These four instructions provide all the crypto- 
graphic processing required to perform any DES opera 
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time. The object being loaded is read into the secure 
area of the cryptographic module 10' and an MDC is 
calculated for the object. This MDC is then compared 
to the stored MDC. If the calculated MDC matches the 
stored MDC, the object is loaded. If the object is a 
UDF Set, it is loaded and made the active set. Only one 
UDF Set can be loaded into the non-volatile lower chip 
18 at one point in time. An option with the LOAD 
OBJECT command determines in what form the UDF 
Set will be sent. 'CIPHERED* specifies that the UDF 
Set is being sent in ciphertext. The user must also spec- 
ify the key, the ICV, and the last block rules. 'CLEAR* 
specifies that the UDF Set is being sent in cleartext. If 
neither 'CIPHERED* nor 'CLEAR* is specified, the 
UDF Set is assumed to be in cleartext. 

The VERIFY OBJECT command is used to provide 
a means of verifying objects at some point in time that 
have been previously registered. The object being veri- 
fied is read into the secure area of the cryptographic 



tions that may be desired on the data being processed by 20 module 10' and an MDC is calculated for the object 



30 



35 



the UDF. 

Managing UDFs and External Objects 

The set of UDF commands includes six commands 
for use in managing UDFs. These commands are REG- 25 
ISTER, LOAD, VERIFY, DELETE, INVOKE, and 
QUERY. It is contemplated, however, that additional 
UDF commands may be implemented. Four of these 
commands, REGISTER, VERIFY, DELETE, and 
QUERY can also be used to manage external objects 
An external object can be any collection of data. All of 
these commands may be authorized in the same way 
any other command may be authorized. This mecha- 
nism provides some control over the individuals who 
may register, load, verify, delete, invoke, and query 
UDFs. Each of these commands is described and dis- 
cussed in greater detail below. 

The REGISTER OBJECT command is used to pro- 
vide a means of registering objects at some point in time 
for the purpose of authenticating them at some future 40 
point in time. The object being registered is passed into 
the secure area of the cryptographic module 10' and a 
Modification Detection Code (MDC) is calculated for 
the object. The MDC is then stored along with the 
object name and other information in an internal object 
table in non-volatile lower chip 18. The registration 
process does not result in the object being loaded, but 
rather in the MDC being calculated and stored along 
with some other information. There are several options 
to choose with the REGISTER OBJECT command. 
The first option determines how to deal with duplicate 
entries. 'NOREPL* specifies that the object is to be 
registered only if there is no duplicate entry in the table. 
'UNCOND* specifies that the object is to be uncondi- 
tionally registered. If there is a duplicate entry in the 55 
table, it is overlaid by the parameters of the current 
object. The second option determines in what form the 
UDF Set will be sent. 'CIPHERED* specifies that the 
UDF Set is being sent in ciphertext. The user must also 
specify the key, the ICV, and the last block rules. 
'CLEAR* specifies that the UDF Set is being sent in 
cleartext. 'If neither 'CIPHERED* nor 'CLEAR* is 
specified, the UDF Set is assumed to be in cleartext. 
The maximum number of objects that can be registered 
at one point in time is 128 in the preferred embodiment. 

The LOAD OBJECT command is used to provide a 
means of loading objects (code) at some point in time 
for the purpose of using them at some future point in 
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This MDC is then compared to the stored MDC. If the 
calculated MDC matches the stored MDC, the object 
has been verified and a successful return code is sent. If 
the object fails to verify, an unsuccessful return code is 
sent. An object that has been registered or loaded is not 
altered by the VERIFY OBJECT command. An option 
with the VERIFY OBJECT command determines in 
what form the UDF Set will be sent. 'CIPHERED* 
specifies that the UDF Set is being sent in ciphertext. 
The user must also specify the key, the ICV, and the last 
block rules. 'CLEAR* specifies that the UDF Set is 
being sent in cleartext. If neither 'CIPHERED* nor 
'CLEAR* is specified, the UDF Set is assumed to be in 
cleartext. 

The DELETE OBJECT command is used to pro- 
vide a means of deleting objects (code) at some point in 
time that have been previously registered by the REG- 
ISTER OBJECT command. An option with the DE- 
LETE OBJECT command determines what is to be 
deleted. 'CODEONLY* specifies that only the object is 
to be erased. The object remains registered. 'ENTRY* 
specifies that the object is to be erased and the entry in 
the internal object table is to be removed. 

The INVOKE CODE command is used to provide a 
means of executing code at some point in time that has 
been previously registered using the REGISTER OB- 
JECT command and loaded using the LOAD OBJECT 
command. 

The QUERY OBJECT command is used to provide 
a means of querying objects at some point in time. An 
option with the QUERY OBJECTcommand deter- 
mines what information is to be returned by the com- 
mand. 'EXIST determines if the object exists in the 
internal object table. Only a return code is returned. 
'TERSE* determines if the object exists in the internal 
object table and if it does, the short form of information 
concerning the object is returned. 'VERBOSE* deter- 
mines if the object exists in the internal object table and 
if it does, the full form of information concerning the 
object is returned. 

Example of a UDF 

One particular Personal Identification Number (PIN) 
derivation algorithm requires the ID of the bank and 
some data related to the customer to derive the PIN. 
The bank ID is encrypted using a cryptographic key. 
The result of this encryption is exclusive-OR'd with the 
complement of the customer data to form a new crypto- 
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graphic key (Kx). The customer data is then encrypted 
using Kx. The encrypted customer data is converted to 
decimal digits by translating 0-9 to 0-9 and A-F to 0-5, 
respectively. The final result is the derived PIN. FIG. 6 
shows a flowchart of the PIN derivation algorithm. 

The input data required to perform the PIN deriva- 
tion algorithm is assembled by the invoking application 
and passed into the UDF. The data is passed when the 
UDF is invoked. The resulting PIN is returned from the 
UDF to the invoking application. The PIN is returned 
when the UDF has completed executing. The contents 
of the I/O buffer when the UDF receives and relin- 
quishes control is shown in Chart 3, below. 

Chart 3 

Contents of the I/O Buffer 
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000 


PIN 




008 


Bank ID 




010 


Customer Data 




018 


e»Km.CV(Key) 





The UDF implementation of the PIN derivation al- 
gorithm is shown in Chart 4, below. 

Chart 4 

UDF Implementation of the PIN Derivation Algorithm 



1 UDFBEG 


SPEC_PIN,ABC, 120,8 < Special PIN UDF> 






; Get key 


2 DEFCON 


2,18 


; Displacement to encrypted key 


3 LDIRI 


8 


; Number of bytes to be loaded 


4 LAR 


2 


; A*Reg = encrypted key 


5 SAVEA 


8 


; SA 8 = encrypted key 


6 DEFCON 


9,00 22 7E 00 03 41 00 00 






; Define control vector 


7 LDKEY 1 


8 


; Kl-Rcg e= clear key 






; Get customer data 


8 DEFCON 


7 t 10 


; Displacement to customer data 


9 LDIRI 


8 


; Number of bytes to be loaded 


10 LAR 


7 


; A-Reg = customer data 


11 MOVEAB 




; B-Reg - customer data 


12 NOTB 




; B-Reg b inverse of customer data 


13 PUSHA 




; Stack » customer data 






; Get bank ID 


14 DEFCON 


5,8 


; Displacement to bank ID 


13 LDIRI 


8 


I Number of bytes to be loaded 


16 LAR 


5 


; A-Reg a bank ID 


17 ENCODE 


K1.A.A 


i A-Reg as encrypted bank ID 






; - eK(bank ID) 


18 XORR 




; B-Reg a Kx s eK(bank ID) xor 






; (inverse of customer data) 


19 POPA 




; A-Reg » customer data 


20 SAVEB 


12 


; SA 12 = Kx 


21 RESTK2 


12 


; K2-Reg = Kx 


22 ENCODE 


K2.A.B 


; B-Reg = encrypted customer data 






; — eKx(customer data) 


23 DEFCON 


14,01 23 45 67 89 01 23 45 






; Define decimalization table 


24 RE ST A 


14 


; A-Reg «=> decimalization table 


25 XNIB 




; Decimalize encrypted customer data 


26 DEFCON 


4,0 


; Displacement to PIN 


27 LDIRI 


8 


; Number of bytes to be loaded 


28 SBR 


4 


; Store PIN in I/O buffer 


29 EXIT 




; UDF complete 


30 UDFEND 







The UDF is assembled using a macroassembler and 
then linked with other UDFs to form a UDF set. The 
UDF Set is registered and loaded and the UDF is in- 
voked. 



The numbers in the leftmost column of Chart 4 are 
used as a reference in the following description of the 
operation of the steps in the UDF. 

Step 1 defines the name of the UDF and other param- 
eters. To invoke the UDF, the name 'SPEC-PIN- 
.ABC is used. The authority level required to invoke 
the UDF if 120 and a maximum of eight bytes may be 
returned from the UDF to the invoking application. 

Step 2 defines the constant 18 into save area 2. The 
value 18 is in hexadecimal and represents the displace- 
ment into the I/O buffer to the encrypted key. The key 
was encrypted using the control vector and the master 
key. 

Step 3 loads the number 8 into the I-Register for use 
by the LAR instruction. 

Step 4 loads the A-Register from the I/O buffer using 
save area 2. Save area 2 contains the value X'18' from 
step 2. The eight bytes located at offset 18 in the I/O 
buffer are loaded into the A-Register. The A-Register 
now contains the encrypted key. 

Step 5 saves the contents of the A-Register in save 
area 8 for use by the LDKEY1 instruction. 

Step 6 defines the control vector into save area 9 for 
use by the LDKEY1 instruction. 

Step 7 loads the clear key into the Kl-Register. The 
encrypted key in save area 8 is combined with the con- 
trol vector in save area 9 to recover the clear key. 

Step 8 defines the constant 10 into save area 7. The 
value 10 is in hexadecimal and represents the displace- 
ment into the I/O buffer to the customer data. 

Step 9 loads the number 8 into the I-Register for use 
by the LAR instruction. 

Step 10 loads the A-Register from the I/O buffer 
using save area 7. Save area 7 contains the value X'10' 
from step 8. The eight bytes located at offset 10 in the 
I/O buffer are loaded into the A-Register. The A-Reg- 
ister now contains the customer data. 

Step 1 1 moves the contents of the A-Register to the 
B-Register. The A-Register is not changed. The B-Reg- 
ister now contains the customer data. The copy of the 
customer data in the B-Register will be inserted and 
exclusive-OR'd with the encrypted bank ID. 

Step 12 complements the copy of the customer data 
in the B-Register. All of the bits in the B-Register are 
45 inverted. 

Step 13 pushed the un-in verted value of the customer 
data in the A-Register onto the stack for later use. 

Step 14 defines the constant 8 into save area 5. The 
value 8 is in hexadecimal and represents the displace- 
ment into the I/O buffer to the bank ID. 

Step 15 loads the number 8 into the I-Register for use 
by the LAR instruction. 

Step 16 loads the A-Register from the I/O buffer 
using save area 5. Save area 5 contains the value X'8' 
from step 14. The eight bytes located at offset 8 in the 
I/O buffer are loaded into the A-Register. The A-Reg- 
ister now contains the bank ID. 

Step 17 encrypts the contents of the A-Register using 
the Key in the Kl-Register and stores the result in the 
A-Register. The A-Register now contains the en- 
crypted bank ID. 

Step 18 exclusive-OR's the encrypted bank ID con- 
tained in the A-Register to the inverse of the customer 
data contained in the B-Register. The result is store din 
the B-Register. The result is the Key Kx which will be 
used for further processing. 

Step 19 pops the un-inverted value of the customer 
data from the stack to the A-Register. 
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Step 20 saves the key Kx in save area 12 for use by the 
RESTK2 instruction. 

Step 21 moves the Key Kx from save area 12 into the 
K2-Register for use by the ENCODE instruction. 

Step 22 encrypts the contents of the A-Register using 
the key (Kx) in the Kl-Register and stores the result in 
the B-Register. The B-Register now contains the en- 
crypted customer data. 

Step 23 defines the decimalization table into save area 
14. This is the table that will be used to convert the 
result of the previous encryption step from values of 
O-F to values of 0-9 for use as a PIN. 

Step 24 moves the decimalization table from save 
area 14 into the A-Register for use by the XNIB instruc- 
tion. 

Step 25 performs the decimalization of the hexadeci- 
mal form of the encrypted customer data in the B-Reg- 
ister. Each nibble in the B-Register is used as an index 
into the A-Register. The value contained at the indexed 
location in the A-Register replaces the index value in 20 
the B-Register. 

Step 26 defines the constant 0 into save area 4. The 
value 0 is in hexadecimal and represents the displace- 
ment into the I/O buffer to the PIN. The PIN will be 
returned to the invoking application. 

Step 27 loads the number 8 into the I-Register for use 
by the SBR instruction. 

Step 28 stores the B-Register to the I/O buffer using 
save area 4. Save area 4 contains the value X'O' from 
step 26. The eight bytes in the B-Register are moved to 
offset 0 in the O/O buffer. The location at offset 0 in the 
I/O buffer now contains the PIN. 

Step 29 exits the UDF. The required operations have 
been executed and the PIN is ready to be returned to the 
invoking application. 

Step 30 marks the end of the UDF for the macroas- 
sembler. 

While the preferred embodiment of the present in- 
vention has been shown and described in detail, it 
should be apparent to those of ordinary skill in the art 
that various adaptations and modifications may be made 
without departing form the scope of the invention. The 
present invention is intended to cover all such adapta- 
tions and modifications that fall within the scope of the 
present invention as defined in the appended claims. 

What is claimed is: 

1. A cryptographic module for storing and operating 
on user defined cryptographic functions, said crypto- 
graphic module providing a physically and electrically 
secure environment, said user defined cryptographic 
functions including instructions arranged in a particular 
sequence to implement a desired cryptographic func- 
tion, said cryptographic module comprising: 
memory for storing said user defined cryptographic 
functions, said memory including: 
code for translating said user defined crypto- 
graphic functions into a machine-executable 
form, and 

code implementing at least one command for oper- 
ating on said machine-executable form of said 60 
user defined cryptographic functions; 
a processing unit connected to said memory for exe- 
cuting said code for translating said user defined 
cryptographic functions into a machine-executable 
form and for executing said code implementing at 
least one command for operating on said machine- 
executable form of said user defined cryptographic 
functions; 



25 



30 



35 



40 



45 



50 



55 



65 



a physical protection device for protecting said cryp- 
tographic module from physical attack; and 

an electrical protection device for protecting said 
cryptographic module from electrical attack. 

2. The cryptographic module of claim 1 wherein said 
code for translating said user defined cryptographic 
functions into a machine-executable form includes an 
interpreter program. 

3. The cryptographic module of claim 1 wherein said 
memory includes erasable programmable read only 
memory and random access memory. 

4. The cryptographic module of claim 3 wherein said 
code for translating said user defined cryptographic 
functions into a machine-executable form is stored in 
said erasable programmable read only memory. 

5. The cryptographic module of claim 4 wherein said 
code for translating said user defined cryptographic 
functions into a machine-executable form includes an 
interpreter program. 

6. The cryptographic module of claim 3 wherein 
there is at least one executable cryptographic function 
stored in said erasable programmable read only mem- 
ory. 

7. The cryptographic module of claim 3 wherein 
there is at least one executable user defined crypto- 
graphic function stored in said random access memory. 

8. The cryptographic module of claim 3 wherein said 
random access memory is non-volatile. 

9. The cryptographic module of claim 1 wherein 
there is at least one executable cryptographic function 
stored in said memory. 

10. The cryptographic module of claim 1 wherein 
there is at least one executable user defined crypto- 
graphic function stored in said memory. 

11. The cryptographic module of claim 1 wherein 
said at least one command for operating on said ma- 
chine-executable form of said user defined crypto- 
graphic functions is selected from the group of com- 
mands consisting of: 

registering said user defined cryptographic functions 
in said memory, 

loading said user defined cryptographic functions 
into said memory, 

verifying that said user defined cryptographic func- 
tions have not been altered since they were regis- 
tered in said memory, 

deleting said user defined cryptographic functions 
form said memory, 

invoking said user defined cryptographic functions, 
and 

querying whether said user defined cryptographic 
functions have been registered in said memory. 

12. The cryptographic module of claim 1 wherein 
said memory further includes code implementing a 
command for registering external objects in said mem- 
ory. 

13. The cryptographic module of claim 12 wherein 
said memory further includes code implementing a 
command for verifying that said external objects have 
not been altered since they were registered in said mem- 
ory. 

14. The cryptographic module of claim 12 wherein 
said memory further includes code implementing a 
command for deleting said external objects from said 
memory. 

15. The cryptographic module of claim 12 wherein 
said memory further includes code implementing a 
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command for querying whether said external objects 
have been registered in said memory. 

16. The cryptographic module of claim 1 wherein 
said processing unit includes a cipher processor and a 
microprocessor. 5 

17. The cryptographic module of claim 1 wherein 
there is memory contained outside of said physically 
and electrically secure environment connected to said 
processing unit. 

18. The cryptographic module of claim 17 wherein 10 
said memory is random access memory. 

19. The cryptographic module of claim 1 wherein 
said physical protection device includes an intrusion 
barrier for. protecting against mechanical intrusion, 
chemical intrusion, temperature modification, and radi- 15 
ation exposure. 

20. The cryptographic module of claim 1 wherein 
said electrical protection device includes electrical cir- 
cuitry that prevents access to said memory while said 
processing unit is performing a read from said memory 20 
and that prevents access to said memory while said 
processing unit is executing an instruction which was 
not fetched from said memory. 

21. The cryptographic module of claim 1 wherein 
there is a master key which is used by said user defined 25 
cryptographic functions to recover keys encrypted 
under said master key and wherein said master key is 
not available to said user defined cryptographic func- 
tions. 

22. The cryptographic module of claim 1 wherein 30 
there is a cryptographic key which is utilized by said 
user defined cryptographic functions if a bit in a control 
vector associated with said cryptographic key is active 
and which is prevented from being utilized by said user 
defined cryptographic functions if said bit in said con- 35 
trol vector associated with said cryptographic key is not 
active. 

23. The cryptographic module of claim 1 wherein 
there are cryptographic keys and a control vector, said 
control vector including bits for use in separating cryp- 40 
tographic keys which are used in said user defined cryp- 
tographic functions and cryptographic keys which are 
used for other purposes. 

24. A method of storing and operating on user de- 
fined cryptographic functions in a cryptographic mod- 45 
ule, the cryptographic module providing a physically 
and electrically secure environment, the user defined 
cryptographic functions including instructions arranged 
in a particular sequence to implement a desired crypto- 
graphic function, said method comprising the steps of: 50 

storing the user defined cryptographic functions in 
memory in the cryptographic module; 

translating the user defined cryptographic functions 
into a machine-executable form; 

operating on the machine-executable form of the user 55 
.defined cryptographic functions in the crypto- 
graphic module; 

protecting the cryptographic module from physical 
attack; and 

protecting the cryptographic module from electrical 60 
attack. 

25. The method of claim 24 wherein said step of trans- 
lating the user defined cryptographic functions into a 
machine-executable form includes the step of interpret- 
ing the user defined cryptographic functions. 65 

26. The method of claim 24 wherein said memory 
includes erasable programmable read only memory and 
random access memory. 
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27. The method of claim 26 further comprising the 
step of storing at least one executable cryptographic 
function in said erasable programmable read only mem- 
ory. 

28. The method of claim 26 further comprising the 
step of storing at least one executable user defined cryp- 
tographic function in said random access memory. 

29. The method of claim 26 wherein said random 
access memory is non-volatile. 

30. The method of claim 24 further comprising the 
step of storing at least one executable cryptographic 
function in said memory. 

31. The method of claim 24 further comprising the 
step of storing at least one executable user defined cryp- 
tographic function in said memory. 

32. The method of claim 31 wherein said step of oper- 
ating on the machine-executable form of the user de- 
fined cryptographic functions in the cryptographic 
module includes the step of executing code implement- 
ing at least one command for operating on the machine- 
executable form of the user defined cryptographic func- 
tions, wherein the at least one command is selected from 
the group of commands consisting of: 

registering said user defined cryptographic functions 

in said memory, 
loading said user defined cryptographic functions 

into said memory, 
verifying that said user defined cryptographic func- 
tions have not been altered since they were regis- 
tered in said memory, 
deleting said user defined cryptographic functions 

from said memory, 
invoking said user defined cryptographic functions, 
and 

querying whether said user defined cryptographic 
functions have been registered in said memory. 

33. The method of claim 24 wherein said step of oper- 
ating on the machine-executable form of the user de- 
fined cryptographic functions in the cryptographic 
module includes the step of executing code implement- 
ing at least one command for operating on the machine- 
executable form of the user defined cryptographic func- 
tions, wherein the at least one command is selected from 
the group of commands consisting of: 

registering said user defined cryptographic functions 

in said memory, 
loading said user defined cryptographic functions 

into said memory, 
verifying that said user defined cryptographic func- 
tions have not been altered since they were regis- 
tered in said memory, 
deleting said user defined cryptographic functions 

from said memory, 
invoking said user defined cryptographic functions, 
and 

querying whether said user defined cryptographic 
functions have been registered in said memory. 

34. The method of claim 24 further comprising the 
step of executing code implementing a command for 
registering external objects in said memory. 

35. The method of claim 34 further comprising the 
step of executing code implementing a command for 
versifying that said external objects have not been al- 
tered since they were registered in said memory, 

36. The method of claim 34 further comprising the 
step of executing code implementing a command for 
deleting said external objects from said memory. 
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37. The method of claim 34 further comprising the 
step of executing code implementing a command for 
querying whether said external objects have been regis- 
tered in said memory. 

38. The method of claim 24 wherein said step of pro- 5 
jecting the cryptographic module from physical attack 
includes the step of protecting the cryptographic mod- 
ule against mechanical intrusion, chemical intrusion, 
temperature modification, and radiation exposure. I0 

39. The method of claim 24 wherein said step of pro- 
tecting the cryptographic module from electrical attack 
includes the step of preventing access to said memory 
while a read is being performed from said memory and 
preventing access to said memory while an instruction 15 
which was not fetched from said memory is being exe- 
cuted. 

40. The method of claim 24 further comprising the 
step of separating cryptographic keys which are used in ^ 
said user defined cryptographic functions and crypto- 
graphic keys which are used for other purposes. 

41. A cryptographic unit having electrical circuitry 
for storing and operating on user defined cryptographic 
functions, said cryptographic unit providing a physi- 25 
cally and electrically secure environment, said user 
defined cryptographic functions including instructions 
arranged in a particular sequence to implement a de- 



sired cryptographic function, said cryptographic unit 
comprising: 

memory for storing said user defined cryptographic 

functions, said memory including: 

code for translating said user defined crypto- 
graphic functions into a machine-executable 
form, and 

code implementing at least one command for oper- 
ating on said machine-executable form of said 
user defined cryptographic functions; 
a processing unit connected to said memory for exe- 
cuting said code for translating said user defined 
cryptographic functions into a machine-executable 
form and for executing said code implementing at 
least one command for operating on said machine- 
executable form of said user defined cryptographic 
functions; 

a physical protection device for protecting said cryp- 
tographic module form physical attack; and 

an electrical protection device for protecting said 
cryptographic module from electrical attack. 

42. The cryptographic unit of claim 41 wherein said 
memory includes erasable programmable read only 
memory and random access memory. 

43. The cryptographic unit of claim 41 wherein said 
processing unit includes a cipher processor and a micro- 
processor. 

***** 
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